Input signal management for vehicle park-assist

ABSTRACT

Method and apparatus are disclosed for input signal management for vehicle park-assist. An example vehicle includes an autonomy unit for remote parking, a communication module, a sensor, and a controller. The controller is to designate a mobile device responsive to determining the remote parking is inactive and receiving an activation request from the mobile device. When the mobile device is designated, the controller also is to process remote parking signals of the mobile device, stop the remote parking when the sensor detects engagement of a door handle, and prevent processing of other nonemergency requests.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to U.S. application Ser. No. ______, DocketNo. 83951862 (NGE File No. 026780.9090) and filed on Apr. 9, 2018, andU.S. application Ser. No. ______, Docket No. 83951858 (NGE File No.026780.9091) and filed on Apr. 9, 2018, which are incorporated herein byreference in their entireties.

TECHNICAL FIELD

The present disclosure generally relates to vehicle park-assist and,more specifically, to input signal management for vehicle park-assist.

BACKGROUND

Many vehicles include functions in which at least some motive functionsof a vehicle are autonomously controlled by the vehicle. For example,some vehicles include cruise control in which the vehicle controlsacceleration and/or deceleration of the vehicle so that a speed of thevehicle is maintained. Some vehicles also include adaptive cruisecontrol in which the vehicle controls acceleration and/or decelerationof the vehicle so that a speed of the vehicle is maintained while alsomaintaining a predetermined following distance from other vehiclesahead. Further, some vehicles include park-assist features in which thevehicle autonomously and/or semi-autonomously controls motive functionsof the vehicle to park the vehicle into a parking spot.

SUMMARY

The appended claims define this application. The present disclosuresummarizes aspects of the embodiments and should not be used to limitthe claims. Other implementations are contemplated in accordance withthe techniques described herein, as will be apparent to one havingordinary skill in the art upon examination of the following drawings anddetailed description, and these implementations are intended to bewithin the scope of this application.

Example embodiments are shown for input signal management for vehiclepark-assist. An example disclosed vehicle includes an autonomy unit forremote parking, a communication module, a sensor, and a controller. Thecontroller is to designate a remote device responsive to determining theremote parking is inactive and receiving an activation request from theremote device. When the remote device is designated, the controller alsois to process remote parking signals of the remote device, stop theremote parking when the sensor detects engagement of a door handle, andprevent processing of other nonemergency requests.

An example disclosed method includes designating, via processor, remotedevice for remote parking responsive to determining the remote parkingis inactive and receiving, via a communication module, an activationrequest from the remote device. The example disclosed method alsoincludes processing, via an autonomy unit, remote parking signals of theremote device and preventing processing of other nonemergency requestsduring the remote parking. The example disclosed method also includesstopping, via the autonomy unit, the remote parking upon a sensordetecting engagement of a door handle.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the invention, reference may be made toembodiments shown in the following drawings. The components in thedrawings are not necessarily to scale and related elements may beomitted, or in some instances proportions may have been exaggerated, soas to emphasize and clearly illustrate the novel features describedherein. In addition, system components can be variously arranged, asknown in the art. Further, in the drawings, like reference numeralsdesignate corresponding parts throughout the several views.

FIG. 1 illustrates an example vehicle configured to communicate with amobile device and a key fob of a user in accordance with the teachingsherein.

FIG. 2 is a block diagram of electronic components of the vehicle ofFIG. 1.

FIG. 3 is a block diagram of electronic components of the mobile deviceof FIG. 1.

FIG. 4 is a block diagram of electronic components of the key fob ofFIG. 1.

FIG. 5 depicts an example system for managing input signals for remotepark-assist of the vehicle of FIG. 1.

FIG. 6 is a flowchart for managing input signals for remote park-assistin accordance with the teachings herein.

FIG. 7 depicts another example system for managing input signals forremote park-assist of the vehicle of FIG. 1.

FIG. 8 is another flowchart for managing input signals for remotepark-assist in accordance with the teachings herein.

FIG. 9 depicts another example system for managing input signals forremote park-assist of the vehicle of FIG. 1.

FIG. 10 is another flowchart for managing input signals for remotepark-assist in accordance with the teachings herein.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

While the invention may be embodied in various forms, there are shown inthe drawings, and will hereinafter be described, some exemplary andnon-limiting embodiments, with the understanding that the presentdisclosure is to be considered an exemplification of the invention andis not intended to limit the invention to the specific embodimentsillustrated.

Many vehicles include functions in which at least some motive functionsof a vehicle are autonomously controlled by the vehicle. For example,some vehicles include cruise control in which the vehicle controlsacceleration and/or deceleration of the vehicle so that a speed of thevehicle is maintained. Some vehicles also include adaptive cruisecontrol in which the vehicle controls acceleration and/or decelerationof the vehicle so that a speed of the vehicle is maintained while alsomaintaining a predetermined following distance from other vehiclesahead.

Further, some vehicles include park-assist features (e.g., a remotepark-assist feature) in which the vehicle autonomously and/orsemi-autonomously controls motive functions of the vehicle to park thevehicle into a parking spot. A remote park-assist feature enables avehicle to be autonomously and/or semi-autonomously parked when a driverof the vehicle has already exited the vehicle. For instance, in order touse a remote park-assist feature to autonomously park a vehicle into aparking spot, the driver (1) positions the vehicle near a parking spot,(2) exits the vehicle, (3) stands near the vehicle and/or the parkingspot, and (4) sends a remote signal (e.g., via a mobile device) to thevehicle to initiate the remote park-assist feature.

In some instances, a vehicle potentially may receive a number of inputsignals from a plurality of sources in a short period of time. Forinstance, a vehicle potentially may receive remote park-assistinitiation signal(s) from mobile device(s); remote keyless entryrequest(s) from key fob(s) and/or phone-as-a-key(s); passive enginestart request(s) from key fob(s) and/or phone-as-a-key(s); door lockand/or unlock request(s) from key fob(s), phone-as-a-key(s), vehiclekeypad(s), door handle sensor(s), gesture sensing system(s) and/orliftgate sensor(s); engine start request(s) from key fob(s),phone-as-a-key(s), and/or vehicle keypad(s); panic signal(s) from keyfob(s), phone-as-a-key(s), and/or vehicle keypad(s); etc. In turn, itpotentially may be difficult to manage vehicle input sources frommultiple sources without interrupting and/or preventing performance of adesired remote park-assist feature.

Example methods and apparatus disclosed herein facilitate a vehicle inperforming remote park-assist features upon request without interruptionby prioritizing input signals sent by devices of a user to initiate theremote park-assist features with input signals sent by other devices toinitiate (other) vehicle features.

Some examples disclosed herein prioritize input requests by designatinga first mobile device for initiating remote park-assist features upon(i) determining that remote parking of the vehicle is currently inactiveand (ii) receiving an activation request from the first mobile device.In such examples, an autonomy unit of the vehicle is to perform motivefunctions of the remote park-assist features that are initiated by thefirst mobile device designated for remote parking. Further, tofacilitate prioritization of input signals, a vehicle controllerprevents the autonomy unit from processing remote park-assist requestssent from other phones-as-keys while the first mobile device isdesignated for remote parking. To prevent potential emergency eventsfrom occurring while remote parking is being performed, the vehiclecontroller is configured to instruct the autonomy unit to stop movementof the vehicle in response to receiving an emergency request while thefirst mobile device is designated for remote parking. For example, anemergency request is received upon detection that an object is in thepath of the vehicle. Further, to enable a user to access a cabin of thevehicle, the vehicle controller is configured to instruct the autonomyunit to stop movement of the vehicle while the first mobile device isdesignated in response to detecting that the user has graspedand/otherwise engaged a door handle of a vehicle door. Additionally, tofurther facilitate prioritization of the remote park-assist requests,the vehicle controller is configured to prevent processing of all othernonemergency requests (e.g., sent from other mobile devices) while thefirst mobile device is designated for remote parking.

Some examples disclosed herein prioritize input requests by monitoring avehicle speed while an autonomy unit of a vehicle is performing motivefunctions for remote parking. In such examples, an autonomy unit of thevehicle performs motive functions for remote parking in response to acommunication module of the vehicle receiving a remote parking signalfrom a mobile device of a user. A vehicle controller also is configuredto receive an unlock request (e.g., from a key fob, a vehicle keypad,etc.) to unlock a vehicle door while the autonomy unit is performing themotive functions of the remote park-assist features. To enable a user toaccess a cabin of the vehicle, the vehicle controller is configured toinstruct the autonomy unit to stop movement of the vehicle in responseto (i) receiving an unlock request and (ii) determining that a vehiclespeed is less than or equal to a threshold speed. The user is able tounlock and/or open a vehicle door when the vehicle is stopped. Further,to facilitate prioritization of input requests while remote parking isbeing performed, the vehicle controller prevents unlocking of thevehicle door in response to (i) receiving the unlock request and (ii)determining that the vehicle speed is greater than the threshold speed.In such instances, the vehicle controller does not instruct the autonomyunit to stop the vehicle and the autonomy unit continues to perform themotive functions for remote parking based upon the remote parkingsignal(s) received from the mobile device of the user.

Some examples disclosed herein prioritize input requests by monitoring anumber of key fobs within a tethering range of a vehicle. In suchexamples, an autonomy unit of the vehicle performs motive functions forremote parking in response to a communication module of the vehiclereceiving a remote parking signal from a mobile device of a user. Avehicle controller also is configured to receive an unlock request froma key fob to unlock a vehicle door while the autonomy unit is performingthe motive functions of the remote park-assist features. To facilitateprioritization of input requests while remote parking is beingperformed, the vehicle controller determines the number of key fobswithin the tethering range of the vehicle upon receiving the unlockrequest while the remote parking is being performed. If the number ofkey fobs is one, the vehicle controller determines that the unlockrequest was sent from a key fob of the user initiating the remoteparking via the mobile device without having to identify a locationand/or distance to the key and/or the mobile device. In turn, thevehicle controller determines that the unlock request was sentaccidentally and prevents processing of the unlock request to facilitateprioritization of the input requests. Further, in some examples, thevehicle controller processes the unlock request in response toidentifying that the number of key fobs within the tethering range istwo or more. In other examples, the vehicle controller attempts todetermine whether the key fob that sent the unlock request is the user'skey fob by comparing a distance between the key fob and the vehicle to adistance between the mobile device and the vehicle. If the key fobdistance matches and/or is within a threshold margin of the mobiledevice distance, the vehicle controller determines that the user's keyfob sent the unlock request and subsequently prevents processing of theunlock request. If the key fob distance does not match and/or is notwithin the threshold margin of the mobile device, the vehicle controllerdetermines that another user's key fob sent the unlock request andsubsequently processes the unlock request.

As used herein, “remote parking,” “vehicle remote park-assist,”“remotepark-assist,” and “RePA” refer to a system in which a vehicle controlsits motive functions without direct steering or velocity input from adriver to autonomously park within a parking spot while the driver islocated outside of the vehicle. For example, an autonomy unit of aremote park-assist system controls the motive functions of the vehicleupon receiving a remote initiation signal from a mobile device of adriver.

As used herein, a “key fob” refers to a dedicated electronic mobiledevice that wirelessly communicates with a vehicle to unlock and/or lockvehicle doors), open and/or close the vehicle door(s), activate anengine of the vehicle, and/or control other function(s) of the vehicle.In some examples, a user of a vehicle utilizes another mobile devicethat functions as a phone-as-a-key for wireless communication with thevehicle. As used herein, a “phone-as-a-key” and a “PaaK” refer to anelectronic mobile device (e.g., a smart phone, a wearable, a smartwatch, a tablet, etc.) that includes hardware and/or software tofunction as a key fob.

As used herein, to “tether” refers to authenticating a mobile device toinitiate remote parking for a vehicle. For example, a vehicle isconfigured to perform remote parking upon receiving instruction(s) to doso from a mobile device that is tethered to the vehicle and isconfigured to not perform remote parking upon receiving instruction(s)from a mobile device that is untethered from the vehicle. As usedherein, a “tethered” device refers to a mobile device that is enabled tosend instructions to a vehicle to perform remote parking. For example, amobile device is tethered to a vehicle responsive to the mobile devicebeing wirelessly communicatively coupled to the vehicle and locatedwithin a predetermined tethering range (e.g., 6 meters) of the vehicle.In such examples, a mobile device that sends instructions to a vehicleto perform remote parking is untethered from the vehicle if the mobiledevice is beyond the tethering range of the vehicle.

As used herein, “passive entry” and “passive-entry” refer to a system ofa vehicle that unlock(s) and/or open(s) one or more doors of the vehicleupon detecting that a key fob and/or phone-as-a-key is proximate to adoor of the vehicle. Some passive entry systems prime a door for openingin response to detecting that a key fob and/or phone-as-a-key isapproaching and/or within a predetermined range of the vehicle. In suchexamples, the door is unlocked in response to detecting that (1) a userhas touched a handle of the door and (2) the key fob and/orphone-as-a-key is proximate to the door when the handle is touched. Asused herein, “passive start” and “passive-start” refer to a system of avehicle that activates ignition of an engine of the vehicle upondetecting that a key fob and/or phone-as-a-key is within a cabin of thevehicle (e.g., such that drive-away is enabled). Some passive startsystems prime an engine for ignition in response to detecting that a keyfob and/or phone-as-a-key is approaching and/or within a predeterminedrange of the vehicle. In such examples, the engine is started inresponse to detecting that (1) a user has engaged an ignition switch ofthe vehicle and (2) the key fob and/or phone-as-a-key is within thecabin when the ignition switch is engaged. As used herein, “passiveentry passive start,” “passive-entry passive-start” and “PEPS” refer toa system of vehicle that is configured to perform passive entry andpassive start for the vehicle.

Turning to the figures, FIG. 1 illustrates an example vehicle 100 inaccordance with the teachings herein. The vehicle 100 may be a standardgasoline powered vehicle, a hybrid vehicle, an electric vehicle, a fuelcell vehicle, and/or any other mobility implement type of vehicle. Thevehicle 100 includes parts related to mobility, such as a powertrainwith an engine, a transmission, a suspension, a driveshaft, and/orwheels, etc. The vehicle 100 may be semi-autonomous (e.g., some routinemotive functions controlled by the vehicle 100) or autonomous (e.g.,motive functions are controlled by the vehicle 100 without direct driverinput). As illustrated in FIG. 1, a user 102 wirelessly communicateswith the vehicle 100 via a mobile device 104 configured to initiateremote park-assist and a key fob 106.

In the illustrated example, the vehicle 100 includes one or more doors108 that enable the user 102 to enter and/or exit from a cabin of thevehicle 100. Further, each of the doors 108 of the illustrated exampleincludes a door handle 110 (also referred to as a handle) and a handlesensor 112 (also referred to as a door handle sensor). The door handle110 enables the user 102 to open and/or close the corresponding one ofthe doors 108. For example, the user 102 grasps and/or otherwise engagesthe door handle 110 to open and/or close the corresponding one of thedoors 108. Further, the handle sensor 112 detects when the door handle110 of a corresponding one of the doors 108 is engaged (e.g., by theuser 102). For example, the handle sensor 112 for each of the doors 108is a capacitive sensor and/or any other sensor that is configured todetect when the door handle 110 is engaged.

Further, one of the doors 108 of the illustrated example (e.g., thefront driver-side door) includes a keypad 114 that is configured toreceive a code from the user 102 (e.g., to unlock the doors 108, tostart an engine, etc.). The keypad 114 includes buttons that are labeledwith characters (e.g., numeric characters, alphabetic characters,alphanumeric characters) to enable the user 102 to identify the buttons.For example, to enable the user 102 to enter a numeric code, one buttonmay be labeled “1-2,” another button may be labeled “3-4,” anotherbutton may be labeled “5-6,” another button may be labeled “7-8,” andanother button may be labeled “9-0.” In other examples, the keypad 114is located on any other of the doors 108 and/or other exterior surfaceof the vehicle 100. Alternatively, the keypad 114 is a virtual keypadprojected onto a surface (e.g., a window) of the vehicle 100. Further,in some examples, the vehicle 100 includes a plurality of keypads thatare located at and/or projected onto different positions on the exteriorsurface of the vehicle 100.

In the illustrated example, the vehicle 100 also includes a liftgate 116and a liftgate sensor 118. For example, the liftgate 116 is a door orpanel that opens upwardly to provide access to a cargo compartmentlocated at a rear of the vehicle 100. The liftgate sensor 118 isconfigured to detect a request from the user 102 to open the liftgate116 via a hands-free liftgate system. For example, the liftgate sensor118 (e.g., a capacitive sensor, a kick sensor, a gesture recognitionsystem utilizing a camera, etc.) is positioned on and/or next to theliftgate 116 to monitor an activation area near the liftgate 116. Whenthe user 102 extends at least a portion of his or her leg (e.g., a foot)into the activation area, the liftgate sensor 118 detects a request toopen the liftgate 116 via the hands-free liftgate system. Further, insome examples, one or more of the doors 108 are configured to actuatedin a similar manner. For example, when the user 102 extends a portion ofhis or her leg and/or arm and/or exerts some other motion, a system ofthe vehicle 100 recognizes such gesture as a command and opens one ormore of the doors 108, vehicle windows, and/or other device of thevehicle 100.

Further, the vehicle 100 of the illustrated example includes proximitysensors 120, cameras 122, and a vehicle speed sensor 124. For example,the proximity sensors 120 are configured to collect data that areutilized to detect and locate nearby objects within the surrounding areaof the vehicle 100. The proximity sensors 120 include radar sensor(s)that detect and locate objects via radio waves, LIDAR sensor(s) thatdetect and locate objects via lasers, ultrasonic sensor(s) that detectand locate objects via ultrasound waves, and/or any other sensor(s) thatare able to detect and locate nearby objects. The cameras 122 areconfigured to capture image(s) and/or video of an area surrounding thevehicle 100 that are utilized to detect and locate nearby objects. Inthe illustrated example, one of the proximity sensors 120 and one of thecameras 122 are front sensing devices that monitor an area in front ofthe vehicle 100. Additionally, one of the proximity sensors 120 and oneof the cameras 122 are rear sensing devices that monitor an area behindthe vehicle 100. Further, the vehicle speed sensor 124 detects a speedat which the vehicle 100 is travelling.

The vehicle 100 also includes a communication module 126 that includeswired or wireless network interfaces to enable communication with otherdevices (e.g., the mobile device 104, the key fob 106) and/or externalnetworks. The external network(s) may be a public network, such as theInternet; a private network, such as an intranet; or combinationsthereof, and may utilize a variety of networking protocols now availableor later developed including, but not limited to, TCP/IP-basednetworking protocols. In such examples, the communication module 126also includes hardware (e.g., processors, memory, storage, antenna,etc.) and software to control the wired or wireless network interfaces.For example, the communication module 126 includes one or morecommunication controllers for short-range network(s), local wirelessarea network(s), cellular(s), and/or other wireless network(s). In theillustrated example, the communication module 126 includes hardware andfirmware to establish a wireless connection with the mobile device 104and/or the key fob 106 of the user 102. For example, the communicationmodule 126 includes communication modules that enable wirelesscommunication with the mobile device 104 and/or the key fob 106 when theuser 102 is proximate to the vehicle 100.

In the illustrated example, the communication module 126 includes a LFmodule 128 (also referred to as a low-frequency communication module, aLF communication module, a low-frequency module), a BLE module 130 (alsoreferred to as a Bluetooth® low-energy communication module, a BLEcommunication module, a Bluetooth® low-energy module), and a cellularmodule 132 (also referred to as a cellular network module). The LFmodule 128 is configured for low-frequency communication. For example,the LF module 128 communicates with the key fob 106 and/or otherdevice(s) via low-frequency signals. The BLE module 130 is configuredfor Bluetooth® and/or BLE protocol communication. For example, the BLEmodule 130 communicates with the mobile device 104 and/or otherdevice(s) via the BLE communication protocol. That is, the BLE module130 implements the Bluetooth® and/or Bluetooth® Low Energy (BLE)protocols. The Bluetooth® and BLE protocols are set forth in Volume 6 ofthe Bluetooth® Specification 4.0 (and subsequent revisions) maintainedby the Bluetooth® Special Interest Group. Further, the cellular module132 is configured for cellular communication. For example, the cellularmodule 132 communicates with the mobile device 104, the key fob 106,remote server(s), and/or other device(s) via cellular communicationprotocol(s), such as Global System for Mobile Communications (GSM),Universal Mobile Telecommunications System (UMTS), Long Term Evolution(LTE), and Code Division Multiple Access (CDMA). Additionally oralternatively, the communication module 126 is configured to wirelesslycommunicate via Wi-Fi communication, Near Field Communication (NFC), UWB(Ultra-Wide Band), ultra-high frequency (UHF) communication, super-highfrequency (SHF) communication (communication at between 3 GHz and 30GHz), and/or any other short-range and/or local wireless communicationprotocol that enables the communication module 126 to communicativelycouple to the mobile device 104, the key fob 106, remote server(s),and/or other device(s).

In the illustrated example, the communication module 126 communicativelycouples to a mobile device (e.g., the mobile device 104, the key fob106) to measure and/or receive measurements of a signal strength (e.g.,a received signal strength indicator) of signals broadcasted by themobile device. For example, the communication module 126 communicativelycouples to a mobile device (e.g., the mobile device 104, the key fob106) to track a distance between the mobile device and the vehicle 100.That is, the communication module 126 receives and analyzes the signalstrength measurements between the mobile device and the communicationmodule 126 to determine a distance between that mobile device and thevehicle 100.

The vehicle 100 of the illustrated example also includes antenna nodes134 that each include hardware (e.g., processors, memory, storage,antenna, etc.) and software to control wireless network interface(s).The antenna nodes 134 include a communication controller for a personalor local area wireless network (e.g., Bluetooth®, Bluetooth® Low Energy(BLE), Zigbee®, Z-Wave®, Wi-Fi®, etc.). In some examples, when theantenna nodes 134 are configured to implement BLE, the antenna nodes 134may be referred to as “BLE Antenna Modules” or “BLEAMs.” The antennanodes 134 communicatively couple to the mobile device 104 and/or otherdevice(s) to measure and/or receive measurements of a signal strength(e.g., a received signal strength indicator) of signals broadcasted bythe mobile device 104. In the illustrated example, the antenna nodes 134include external nodes that facilitate determining when the mobiledevice 104, the key fob 106, and/or other remote device(s) are outsideof the vehicle 100. For example, the antenna nodes 134 include anantenna node 134 a, an antenna node 134 b, an antenna node 134 c, anantenna node 134 d, an antenna node 134 e, and an antenna node 134 f.Further, in some examples, the antenna nodes 134 include one or moreinternal nodes that are located within a cabin of the vehicle 100 tofacilitate determining when the mobile device 104, the key fob 106,and/or other remote device(s) are within the cabin of the vehicle 100.

The communication module 126 is communicatively coupled to the antennanodes 134 to track a location of the mobile device 104, the key fob 106,and/or other remote device(s) relative to the vehicle 100. In someexamples, when the antenna nodes 134 are configured to implement BLE,the BLE module 130 of the communication module 126 may be referred to asa “BLEM.” The communication module 126 receives and analyzes the signalstrength measurements between the communication module 126 and a mobiledevice (e.g., the mobile device 104, the key fob 106). Based on thesemeasurements, the communication module 126 determines a location of thatmobile device relative to the vehicle 100.

The vehicle 100 of the illustrated example also includes a body controlmodule 136 that controls various subsystems of the vehicle 100. Forexample, the body control module 136 is configured to control animmobilizer system, and/or power mirrors, etc. The body control module136 is electrically coupled to circuits that, for example, drive relays(e.g., to control wiper fluid, etc.), drive brushed direct current (DC)motors (e.g., to control power seats, power locks, power windows,wipers, etc.), drive stepper motors, and/or drive LEDs, etc. In theillustrated example, the body control module 136 controls door controlunits that control the electronic locks and electronic windows of thevehicle 100. Additionally, the body control module 136 controls theexterior lights of the vehicle 100. For example, when an authorizedmobile device (e.g., the mobile device 104, the key fob 106) is within apredetermined zone of the vehicle 100, the body control module 136controls various subsystems of the vehicle 100 to activate inanticipation of the user 102 reaching the vehicle 100. For example, thebody control module 136 may activate the exterior lights, change theposition of a driver's seat, primes one or more of the doors 108 and/orthe liftgate 116 to unlock upon the handle sensor 112 and/or theliftgate sensor 118, respectively, detecting the presence of the user102.

Further, the vehicle 100 of the illustrated example includes an autonomyunit 138 and a RePA controller 140. For example, the autonomy unit 138controls performance of autonomous and/or semi-autonomous drivingmaneuvers of the vehicle 100 based upon, at least in part, image(s)and/or video captured by one or more of the cameras 122 and/or datacollected by one or more of the proximity sensors 120. The RePAcontroller 140 is configured to manage input signal(s) received from themobile device 104, the key fob 106, other mobile device(s), the keypad114, the handle sensors 112, the liftgate sensor 118, the proximitysensors 120, the cameras 122, and/or other data source(s) for thevehicle 100 prior to and/or while the autonomy unit 138 is performingautonomous and/or semi-autonomous driving maneuvers for remotepark-assist.

FIG. 2 is a block diagram of electronic components 200 of the vehicle100. In the illustrated example, the electronic components 200 includean on-board computing platform 201, the communication module 126, theantenna nodes 134, the keypad 114, the cameras 122, sensors 202,electronic control units 204 (ECUs), and a vehicle data bus 206.

The on-board computing platform 201 includes a microcontroller unit,controller or processor 208 and memory 210. In some examples, theprocessor 208 of the on-board computing platform 201 is structured toinclude the RePA controller 140. Alternatively, in some examples, theRePA controller 140 is incorporated into another ECU (e.g., the bodycontrol module 136) and/or other device (e.g., the communication module126) with its own processor and memory. The processor 208 may be anysuitable processing device or set of processing devices such as, but notlimited to, a microprocessor, a microcontroller-based platform, anintegrated circuit, one or more field programmable gate arrays (FPGAs),and/or one or more application-specific integrated circuits (ASICs). Thememory 210 may be volatile memory (e.g., RAM including non-volatile RAM,magnetic RAM, ferroelectric RAM, etc.), non-volatile memory (e.g., diskmemory, FLASH memory, EPROMs, EEPROMs, memristor-based non-volatilesolid-state memory, etc.), unalterable memory (e.g., EPROMs), read-onlymemory, and/or high-capacity storage devices (e.g., hard drives, solidstate drives, etc.). In some examples, the memory 210 includes multiplekinds of memory, particularly volatile memory and non-volatile memory.

The memory 210 is computer readable media on which one or more sets ofinstructions, such as the software for operating the methods of thepresent disclosure, can be embedded. The instructions may embody one ormore of the methods or logic as described herein. For example, theinstructions reside completely, or at least partially, within any one ormore of the memory 210, the computer readable medium, and/or within theprocessor 208 during execution of the instructions.

The terms “non-transitory computer-readable medium” and“computer-readable medium” include a single medium or multiple media,such as a centralized or distributed database, and/or associated cachesand servers that store one or more sets of instructions. Further, theterms “non-transitory computer-readable medium” and “computer-readablemedium” include any tangible medium that is capable of storing, encodingor carrying a set of instructions for execution by a processor or thatcause a system to perform any one or more of the methods or operationsdisclosed herein. As used herein, the term “computer readable medium” isexpressly defined to include any type of computer readable storagedevice and/or storage disk and to exclude propagating signals.

As illustrated in FIG. 2, the communication module 126 of the electroniccomponents 200 includes the LF module 128, the BLE module 130, and thecellular module 132. Further, the electronic components 200 include theantenna nodes 134, the keypad 114, and the cameras 122.

The electronic components 200 of the illustrated example also includethe sensors 202 that are arranged in and around the vehicle 100 tomonitor properties of the vehicle 100 and/or an environment in which thevehicle 100 is located. One or more of the sensors 202 may be mounted tomeasure properties around an exterior of the vehicle 100. Additionallyor alternatively, one or more of the sensors 202 may be mounted inside acabin of the vehicle 100 or in a body of the vehicle 100 (e.g., anengine compartment, wheel wells, etc.) to measure properties in aninterior of the vehicle 100. For example, the sensors 202 includeaccelerometers, odometers, tachometers, pitch and yaw sensors, wheelspeed sensors, microphones, tire pressure sensors, biometric sensorsand/or sensors of any other suitable type. In the illustrated example,the sensors 202 include the handle sensors 112, the liftgate sensor 118,the proximity sensors 120, and the vehicle speed sensor 124.

The ECUs 204 monitor and control the subsystems of the vehicle 100. Forexample, the ECUs 204 are discrete sets of electronics that includetheir own circuit(s) (e.g., integrated circuits, microprocessors,memory, storage, etc.) and firmware, sensors, actuators, and/or mountinghardware. The ECUs 204 communicate and exchange information via avehicle data bus (e.g., the vehicle data bus 206). Additionally, theECUs 204 may communicate properties (e.g., status of the ECUs 204,sensor readings, control state, error and diagnostic codes, etc.) toand/or receive requests from each other. For example, the vehicle 100may have dozens of the ECUs 204 that are positioned in various locationsaround the vehicle 100 and are communicatively coupled by the vehicledata bus 206. In the illustrated example, the ECUs 204 include the bodycontrol module 136 and the autonomy unit 138.

The vehicle data bus 206 communicatively couples the keypad 114, thecameras 122, the antenna nodes 134, the communication module 126, theon-board computing platform 201, the sensors 202, and the ECUs 204. Insome examples, the vehicle data bus 206 includes one or more data buses.The vehicle data bus 206 may be implemented in accordance with acontroller area network (CAN) bus protocol as defined by InternationalStandards Organization (ISO) 11898-1, a Media Oriented Systems Transport(MOST) bus protocol, a CAN flexible data (CAN-FD) bus protocol (ISO11898-7) and/a K-line bus protocol (ISO 9141 and ISO 14230-1), and/or anEthernet™ bus protocol IEEE 802.3 (2002 onwards), etc.

FIG. 3 is a block diagram of electronic components 300 of the mobiledevice 104. In the illustrated example, the electronic components 300include a processor 302, memory 304, a communication module 306, atouchscreen 308, and a speaker 310.

The processor 302 may be any suitable processing device or set ofprocessing devices such as, but not limited to, a microprocessor, amicrocontroller-based platform, an integrated circuit, one or more fieldprogrammable gate arrays (FPGAs), and/or one or moreapplication-specific integrated circuits (ASICs).

The memory 304 may be volatile memory (e.g., RAM including non-volatileRAM, magnetic RAM, ferroelectric RAM, etc.), non-volatile memory (e.g.,disk memory, FLASH memory, EPROMs, EEPROMs, memristor-based non-volatilesolid-state memory, etc.), unalterable memory (e.g., EPROMs), read-onlymemory, and/or high-capacity storage devices (e.g., hard drives, solidstate drives, etc.). In some examples, the memory 304 includes multiplekinds of memory, particularly volatile memory and non-volatile memory.

The memory 304 is computer readable media on which one or more sets ofinstructions, such as the software for operating the methods of thepresent disclosure, can be embedded. The instructions may embody one ormore of the methods or logic as described herein. For example, theinstructions reside completely, or at least partially, within any one ormore of the memory 304, the computer readable medium, and/or within theprocessor 302 during execution of the instructions.

The communication module 306 of the illustrated example includes wiredor wireless network interfaces to enable communication with otherdevices and/or external networks. The external network(s) may be apublic network, such as the Internet; a private network, such as anintranet; or combinations thereof, and may utilize a variety ofnetworking protocols now available or later developed including, but notlimited to, TCP/IP-based networking protocols. The communication module306 also includes hardware (e.g., processors, memory, storage, antenna,etc.) and software to control the wired or wireless network interfaces.For example, the communication module 306 includes one or morecommunication controllers for cellular networks, such as Global Systemfor Mobile Communications (GSM), Universal Mobile TelecommunicationsSystem (UMTS), Long Term Evolution (LTE), Code Division Multiple Access(CDMA). In the illustrated example, the communication module 306includes a wireless personal area network (WPAN) module that isconfigured to wirelessly communicate with the communication module 126of the vehicle 100 via short-range wireless communication protocol(s).In some examples, the communication module 306 implements the Bluetooth®and/or Bluetooth® Low Energy (BLE) protocols. Additionally oralternatively, the communication module 306 is configured to wirelesslycommunicate via Wi-Fi®, Near Field Communication (NFC), ultra-wide band(UWB) communication, super-high frequency (SHF) communication,ultra-high frequency (UHF) communication, low-frequency (LF)communication, and/or any other communication protocol that enables thecommunication module 306 to communicatively couple to the communicationmodule 126 of the vehicle 100.

The touchscreen 308 of the illustrated example provides an interfacebetween the user 102 and the mobile device 104 to enable the user 102 toinitiate remote park-assist and/or other function(s) for the vehicle100. For example, the touchscreen 308 is a resistive touchscreen, acapacitive touchscreen, and/or any other type of touchscreen thatdisplays output information to and tactilely receives input informationfrom the user 102 of the mobile device 104. In some examples, theelectronic components 300 of the mobile device 104 also includes otherinput devices (e.g., buttons, knobs, microphones, etc.) and/or outputdevices, such as a speaker 310, LEDs, etc., to receive input informationfrom and/or provide output information to the user 102 of the mobiledevice 104. The user 102 interacts with the touchscreen 308 to initiateremote park-assist and/or other vehicle function(s) via the mobiledevice 104. Based on input received from the user 102 via thetouchscreen 308, the communication module 306 of the mobile device 104wirelessly communicates with the communication module 126 of the vehicle100 to initiate motive functions for remote park-assist and/or otherfunction(s) of the vehicle 100.

FIG. 4 is a block diagram of electronic components 400 of the key fob106. In the illustrated example, the electronic components 400 include aprocessor 402, memory 404, a communication module 406, a lock button408, an unlock button 410, an open button 412, and an emergency button414.

The processor 402 may be any suitable processing device or set ofprocessing devices such as, but not limited to, a microprocessor, amicrocontroller-based platform, an integrated circuit, one or more fieldprogrammable gate arrays (FPGAs), and/or one or moreapplication-specific integrated circuits (ASICs).

The memory 404 may be volatile memory (e.g., RAM including non-volatileRAM, magnetic RAM, ferroelectric RAM, etc.), non-volatile memory (e.g.,disk memory, FLASH memory, EPROMs, EEPROMs, memristor-based non-volatilesolid-state memory, etc.), unalterable memory (e.g., EPROMs), read-onlymemory, and/or high-capacity storage devices (e.g., hard drives, solidstate drives, etc.). In some examples, the memory 404 includes multiplekinds of memory, particularly volatile memory and non-volatile memory.

The memory 404 is computer readable media on which one or more sets ofinstructions, such as the software for operating the methods of thepresent disclosure, can be embedded. The instructions may embody one ormore of the methods or logic as described herein. For example, theinstructions reside completely, or at least partially, within any one ormore of the memory 404, the computer readable medium, and/or within theprocessor 402 during execution of the instructions.

The communication module 406 of the illustrated example includes wiredor wireless network interfaces to enable communication with otherdevices and/or external networks. The external network(s) may be apublic network, such as the Internet; a private network, such as anintranet; or combinations thereof, and may utilize a variety ofnetworking protocols now available or later developed including, but notlimited to, TCP/IP-based networking protocols. The communication module406 also includes hardware (e.g., processors, memory, storage, antenna,etc.) and software to control the wired or wireless network interfaces.For example, the communication module 406 includes one or morecommunication controllers for cellular networks, such as Global Systemfor Mobile Communications (GSM), Universal Mobile TelecommunicationsSystem (UMTS), Long Term Evolution (LTE), Code Division Multiple Access(CDMA). In the illustrated example, the communication module 406includes a wireless personal area network (WPAN) module that isconfigured to wirelessly communicate with the communication module 126of the vehicle 100 via short-range wireless communication protocol(s).In some examples, the communication module 406 implements the Bluetooth®and/or Bluetooth® Low Energy (BLE) protocols. Additionally oralternatively, the communication module 406 is configured to wirelesslycommunicate via Wi-Fi®, Near Field Communication (NFC), ultra-wide band(UWB) communication, super-high frequency (SHF) communication,ultra-high frequency (UHF) communication, low-frequency (LF)communication, and/or any other communication protocol that enables thecommunication module 406 to communicatively couple to the communicationmodule 126 of the vehicle 100.

Further, the lock button 408, the unlock button 410, the open button412, and the emergency button 414 of the electronic components 400provide an interface between the user 102 and the key fob 106 to enablethe user 102 to function(s) for the vehicle 100. Based on the inputreceived from the user 102 via the lock button 408, the unlock button410, the open button 412, and/or the emergency button 414, thecommunication module 406 of the key fob 106 wirelessly communicates withthe communication module 126 of the vehicle 100 to initiate function(s)of the vehicle 100. For example, upon the user 102 pressing the lockbutton 408, the communication module 406 is configured to send a signalto the communication module 126 of the vehicle 100 to instruct the bodycontrol module 136 to lock one or more of the doors 108. Upon the user102 pressing the unlock button 410, the communication module 406 isconfigured to send a signal to the communication module 126 of thevehicle 100 to instruct the body control module 136 to unlock one ormore of the doors 108. Upon the user 102 pressing the open button 412,the communication module 406 is configured to send a signal to thecommunication module 126 of the vehicle 100 to instruct the body controlmodule 136 to open one or more of the doors 108. Further, upon the user102 pressing the emergency button 414, the communication module 406 isconfigured to send a signal to the communication module 126 of thevehicle 100 to instruct the body control module 136 to emit an emergencyalarm (e.g., via a horn, exterior lamps, etc.). Additionally oralternatively, the electronic components 400 of the key fob 106 includeother input devices (e.g., other buttons) and/or output devices toreceive input information from and/or provide output information to theuser 102.

FIG. 5 depicts an example system for managing input signals for remotepark-assist of the vehicle 100. In the illustrated example, the user 102utilizes the mobile device 104 to initiate the performance ofremote-park assist motive functions by the autonomy unit 138 toautonomously park the vehicle 100 within a parking spot 502.

The vehicle 100 of the illustrated example is permitted to autonomouslyperform motive functions for remote park-assist when the user 102 iswithin a tethering range 504 of the vehicle 100 and is prohibited fromautonomously performing the motive functions when the user 102 isoutside of the tethering range 504. For instance, some governmental haveinstituted regulations that require the user 102 be within the tetheringrange 504 of the vehicle 100 while the vehicle 100 is autonomouslyperforming remote park-assist motive functions. The tethering range 504of the illustrated example is defined to extend to a predetermineddistance (e.g., 6 meters) from an exterior surface of the vehicle 100.The user 102 is within the tethering range 504 of the vehicle 100 if adistance between the user 102 and the exterior surface of the vehicle100 is less than or equal to the predetermined distance of the tetheringrange 504.

In the illustrated example, the RePA controller 140 determines thedistance between the user 102 and the exterior surface of the vehicle100 by determining a distance between the key fob 106 of the user 102and the communication module 126 of the vehicle 100. For example, thekey fob 106 communicates with the communication module 126 of thevehicle via low-frequency communication. Further, the mobile device 104communicates with the communication module 126 of the vehicle 100 viathe BLE communication protocol, the Wi-Fi communication protocol, and/orsuper-high frequency communication. In the illustrated example, the RePAcontroller 140 determines the distance between the user 102 and thevehicle 100 based upon the low-frequency communication of the key fob106 rather than the wireless communication of the mobile device 104,because calculating a distance based upon RSSI of low-frequencycommunication is more accurate than calculating a distance based uponRSSI of BLE, Wi-Fi, and/or super-high frequency communication. That is,because the key fob 106 has a LF communication module for low-frequencycommunication with the communication module 126 of the vehicle 100, theRePA controller 140 utilizes the RSSI of communication between the keyfob 106 and the communication module 126 to approximate a distancebetween the user 102 and the vehicle 100.

The vehicle 100 of the illustrated example also corresponds with athreshold range 506 that is greater than and/or extends beyond thetethering range 504. The RePA controller 140 utilizes the thresholdrange 506 to limit a distance from which some other vehicle functionsmay be remotely initiated by a remote device associated with the vehicle100. For example, the RePA controller 140 permits other vehiclefunctions (e.g., passive entry, passive engine start, remote unlocking,remote opening, remote engine start, etc.) to be initiated by a mobiledevice that is located within the threshold range 506 and prohibitsthose other vehicle functions from being initiated by a mobile devicethat is located beyond the threshold range 506. In some examples, thethreshold distance is defined based upon, at least in part, thelimitations of the communication protocol(s) utilized for wirelesscommunication between mobile device(s) and the communication module 126of the vehicle 100. Further, in some examples, the RePA controller 140permits some vehicle functions (e.g., emergency functions) to beremotely initiated by a remote device (e.g., by sending an emergencysignal) that is located beyond the threshold range 506.

In operation, the RePA controller 140 determines whether remotepark-assist is active for the vehicle 100. That is, the RePA controller140 identifies whether the autonomy unit 138 is performing motivefunctions for remote park-assist that were initiated from the mobiledevice 104 of the user 102 and/or another mobile device 104 of anotheruser associated with the vehicle 100. If the RePA controller 140determines that the remote park-assist is inactive, the RePA controller140 waits to designate a mobile device for initiating remotepark-assist. For example, when the remote park-assist of the vehicle 100is inactive, the RePA controller 140 designates a mobile device uponreceiving, via the communication module 126, an activation request fromthe mobile device. That is, the RePA controller 140 is configured todesignate the mobile device 104 of the user in response to RePAcontroller 140 (i) determining that the remote park-assist is inactiveand (ii) receiving an activation request from the mobile device 104. Insome examples, the mobile device 104 sends the activation request uponthe user opening a remote parking app via the touchscreen 308 of themobile device 104.

When the RePA controller 140 designates a mobile device, the RePAcontroller 140 (i) enables that mobile device to initiate remotepark-assist motive functions and (ii) prevents other mobile device(s)from initiating remote park-assist motive functions while another mobiledevice is designated. By preventing the autonomy unit 138 fromprocessing remote park-assist requests sent from other mobile device(s)while the phone-as-a-104 key is designated for remote park-assist, theRePA controller 140 facilitates prioritization and processing of inputrequests while remote park-assist is being performed.

In the illustrated example, the autonomy unit 138 of the vehicle 100activates the remote park-assist in response to the RePA controller 140designating the mobile device 104 for the remote park-assist. That is,upon designating the mobile device 104, the RePA controller 140instructs the autonomy unit 138 to activate one or more remotepark-assist features. Further, the RePA controller 140 processes remoteparking signals received by the communication module 126 from the mobiledevice 104 when the mobile device 104 is designated for remotepark-assist of the vehicle 100.

The autonomy unit 138 is configured to perform motive functions forremote park-assist based upon the remote parking signals that are sentfrom the mobile device 104, received by the communication module 126,and processed by the RePA controller 140. For example, the autonomy unit138 performs motive functions for remote park-assist based upon remoteparking signals sent by the mobile device 104 of the user 102 if theRePA controller 140 determines that the key fob 106 of the user 102 iswithin the tethering range 504 of the vehicle 100 at the time the remoteparking signals are sent from the mobile device 104. That is, theautonomy unit 138 performs motive functions for remote park-assist whenthe user 102 is within the tethering range 504 and does not performmotive functions for remote park-assist when the user 102 is beyond thetethering range 504. To determine whether the user 102 is within thetethering range 504 of the vehicle 100, the RePA controller 140determines a distance between the user 102 and the vehicle 100 andsubsequently compares that distance to a distance of the tethering range504. For example, to determine the distance between the user 102 and thevehicle 100, the RePA controller 140 determines the distance between thekey fob 106 of the user 102 and the communication module 126 of thevehicle 100 based upon signal strengths (RSSIs) of the wirelesscommunication (e.g., BLE protocol communication) between the key fob 106and the communication module 126. Further, in some examples, the RePAcontroller 140 determines that both the key fob 106 and the mobiledevice 104 correspond to the user 102 upon identifying that the distanceto and/or location of the key fob 106 with respect to the vehicle 100(e.g., determined based upon RSSIs of communication between the key fob106 and the communication module 126) corresponds with the distance toand/or location of the mobile device 104 with respect to the vehicle 100(e.g., determined based upon RSSIs of communication between the mobiledevice 104 and the communication module 126).

In the illustrated example, to prevent potential emergency events fromoccurring while remote parking is being performed, the RePA controller140 also is configured to instruct the autonomy unit 138 to stopmovement of the vehicle 100 and performance of remote park-assist inresponse to receiving an emergency signal while the mobile device 104 issending remote parking signals to the vehicle 100. That is, the autonomyunit 138 is configured to stop motive functions of the vehicle 100 forremote park-assist upon receipt of an emergency signal. For example, anemergency signal is transmitted for an emergency event upon detectingthat an obstacle (e.g., a person, an animal, an inanimate object) ispositioned along a vehicle path for the motive functions of the vehicle100. In the illustrated example, an emergency signal is transmitted uponthe RePA controller 140 detecting, via one or more of the proximitysensors 120 and/or the cameras 122, that an object 508 (e.g., a trashcan) is within the parking spot 502 into which the vehicle 100 is beingparked. Additionally or alternatively, the communication module 126 ofthe vehicle 100 receives an emergency signal from a nearby mobile device(e.g., a phone-as-a-key, a key fob). For example, the user 102 is ableto send an emergency signal via the key fob 106 upon seeing that theobject 508 is within the path of the vehicle 100. Another user 510 thatis within the threshold range 506 of the vehicle 100 also is able tosend an emergency signal via a mobile device 512 and/or a key fob 514upon seeing that the object 508 is within the path of the vehicle 100.In the illustrated example, the mobile device 512 includesphone-as-a-key and/or remote park-assist functionality. In someexamples, the emergency signal sent from a key fob (e.g., the key fob106, the key fob 514) includes a panic request signal that is sent by auser (e.g., the user 102, the user 510) pressing an emergency button(e.g., the emergency button 414) of the key fob. In some examples, theemergency signal sent from a key fob (e.g., the key fob 106, the key fob514) includes a series of requests (e.g., two remote unlock requests)that are sent by a user (e.g., the user 102, the user 510) by pressing apredefined sequence of button(s) of the key fob (e.g., sending tworemote unlock request signals in succession) within a predefined periodof time (e.g., two seconds). In some examples, the predefined sequenceof button(s) of a key fob may be configurable to user preferences. Insome examples, the emergency signal sent from a key fob (e.g., the keyfob 106, the key fob 514) includes a sequence in which a button (e.g.,an unlock button, a lock button) is continuously pressed by a user(e.g., the user 102, the user 510) for a predefined period of time.Further, in some examples, the emergency signal sent from a key fob(e.g., the key fob 106, the key fob 514) includes a sequence in whichtwo or more buttons (e.g., an unlock button and an emergency button) arepressed simultaneously by a user (e.g., the user 102, the user 510).

To enable a user (e.g., the user 102, the user 510) to access a cabin ofthe vehicle 100, the RePA controller 140 of the illustrated example alsois configured to instruct the autonomy unit 138 to stop movement of thevehicle 100 and performance of remote park-assist in response toreceiving an unlock trigger signal to unlock one or more of the doors108 of the vehicle 100. For example, an unlock trigger signal isreceived in response to (1) one of the handle sensors 112 detecting thata user has grasped and/or otherwise engaged the door handle 110 of thecorresponding one of the doors 108 and (2) the RePA controller 140detecting that a key fob and/or mobile device is near the correspondingone of the doors 108. That is, the RePA controller 140 is configured tounlock one or more of the doors 108 in response to (1) one of the handlesensors 112 detecting that a user (e.g., the user 102, the user 510) hasgrasped and/or otherwise engaged the door handle 110 of thecorresponding one of the doors 108 and (2) the RePA controller 140detecting that a key fob and/or mobile device is near the correspondingone of the doors 108 when the vehicle 100 is stationary.

In the illustrated example, the RePA controller 140 further facilitatesprioritization and processing of input requests while remote park-assistis being performed by preventing processing of other nonemergencyrequests for the vehicle 100 (e.g., passive-entry passive-start signals,remote keyless entry signals, remote door unlock requests, etc.) whileremote park-assist is active. For example, the RePA controller 140 isconfigured to receive a nonemergency request via a mobile deviceincluding phone-as-a-key functionality (e.g., the mobile device 104, themobile device 512), a key fob (e.g., the key fob 106, the key fob 514),the keypad 114, the liftgate sensor 118, a cellular network, etc. Insome examples, when the mobile device 104 of the user 102 is designatedfor remote park-assist for the vehicle 100, a nonemergency requestincludes an activation request from the mobile device 512 of the user510. In such examples, the RePA controller 140 does not process therequest to designate the mobile device 512. Rather, the RePA controller140 is configured to send, via the communication module 126, an alert tothe mobile device 512 indicating that (i) the mobile device 104 of theuser 102 is currently designated for remote park-assist of the vehicle100 and/or (ii) a duration of time during which the mobile device 104will remain designated for the remote park-assist. Additionally oralternatively, when the vehicle 100 is stationary, the RePA controller140 is configured to send, via the communication module 126, a requestto the mobile device 104 of the user 102 for permission to changedesignation for the remote park-assist of the vehicle 100 to the mobiledevice 512 of the user 510.

FIG. 6 is a flowchart of an example method 600 to manage input signalsfor remote park-assist. The flowchart of FIG. 6 is representative ofmachine readable instructions that are stored in memory (such as thememory 210 of FIG. 2) and include one or more programs which, whenexecuted by a processor (such as the processor 208 of FIG. 2), cause thevehicle 100 to implement the example RePA controller 140 of FIGS. 1 and2. While the example program is described with reference to theflowchart illustrated in FIG. 6, many other methods of implementing theexample RePA controller 140 may alternatively be used. For example, theorder of execution of the blocks may be rearranged, changed, eliminated,and/or combined to perform the method 600. Further, because the method600 is disclosed in connection with the components of FIGS. 1-5, somefunctions of those components will not be described in detail below.

Initially, at block 602, the RePA controller 140 determines whetherremote park-assist for the vehicle 100 is active. In response to theRePA controller 140 determining that remote park-assist is activated,the method 600 proceeds to block 608. Otherwise, in response to the RePAcontroller 140 determining that remote park-assist is not activated, themethod 600 proceeds to block 604. At block 604, the RePA controller 140determines whether the communication module 126 of the vehicle 100 hasreceived an activation request from a mobile device (e.g., the mobiledevice 104 of the user 102) to activate remote park-assist for thevehicle 100. In response to the RePA controller 140 determining that anactivation request has not been received, the method 600 returns toblock 602. Otherwise, in response to the RePA controller 140 determiningthat an activation request has been received, the method 600 proceeds toblock 606.

At block 606, the RePA controller 140 designates the mobile device 104that sent the activation request for initiation of remote park-assistfeatures. At block 608, the RePA controller 140 determines whether theuser 102 of the mobile device 104 is within the tethering range 504 ofthe vehicle 100 for initiating remote park-assist features. For example,the RePA controller 140 determines whether the user 102 is within thetethering range 504 based upon signal strengths of communication betweenthe communication module 126 of the vehicle 100 and the key fob 106 ofthe user 102. In response to the RePA controller 140 determining thatthe user 102 is outside of the tethering range 504, the method 600returns to block 602. Otherwise, in response to the RePA controller 140determining that the user 102 is within the tethering range 504, theautonomy unit 138 activates remote park-assist and the method 600proceeds to block 610.

At block 610, the autonomy unit 138 performs remote park-assist motivefunctions that are initiated by the mobile device 104 of the user 102.At block 612, the RePA controller 140 determines whether the vehicle 100has received another input request (e.g., via the communication module126, the handle sensors 112, the keypad 114, the liftgate sensor 118,etc.). In response to the RePA controller 140 determining that anotherinput request has not been received, the method 600 returns to block602. Otherwise, in response to the RePA controller 140 determining thatanother input request has been received, the method 600 proceeds toblock 614.

At block 614, the RePA controller 140 determines whether the other inputrequest is an unlock trigger signal to unlock one or more of the doors108 of the vehicle 100. For example, an unlock trigger signal isreceived upon (1) one of the handle sensors 112 detecting that a userhas grasped and/or otherwise engaged the door handle 110 of thecorresponding one of the doors 108 and (2) the RePA controller 140detecting that a key fob and/or mobile device is near the correspondingone of the doors 108. In response to the RePA controller 140 determiningthat the other input request is an unlock trigger signal, the method 600proceeds to block 618. Otherwise, in response to the RePA controller 140determining that the other input request is not an unlock triggersignal, the method 600 proceeds to block 616.

At block 616, the RePA controller 140 determines whether the other inputrequest is an emergency request. For example, an emergency request maybe received from the key fob 106 of the user 102, the key fob 514 and/orthe mobile device 512 of the user 510, etc. and/or based uponinformation collected by one or more of the proximity sensors 120, oneor more of the cameras 122, etc. In response to the RePA controller 140determining that the other input request is an emergency request, themethod 600 proceeds to block 618. At block 618, the RePA controller 140causes the autonomy unit 138 to stop movement of the vehicle 100 andperformance of remote park-assist. Otherwise, in response to the RePAcontroller 140 determining that the other input request is not anemergency request, the method 600 proceeds to block 620.

At block 620, the RePA controller 140 determines whether the other inputrequest is a RePA activation request from another mobile device (e.g.,the mobile device 512 of the user 510). In response to the RePAcontroller 140 determining that the other input request is an activationrequest from the mobile device 512, the method 600 proceeds to block622. At block 622, the RePA controller 140 sends an alert, via thecommunication module 126, to the mobile device 512 indicating that themobile device 104 of the user 102 is currently designated for remotepark-assist. In the illustrated example, the method 600 also proceeds toblock 624 at which the RePA controller 140 sends, a request to themobile device 104 on behalf of the user 510 for permission to changedesignation for remote park-assist to the mobile device 512 of the user510. Returning to block 620, in response to the RePA controller 140determining that the other input request is not a RePA activationrequest from another mobile device, the method 600 proceeds to block 626at which the RePA controller 140 prevents processing of the other inputrequest.

FIG. 7 depicts another example system for managing input signals forremote park-assist of the vehicle 100. In the illustrated example, theuser 102 utilizes the mobile device 104 when the user 102 is within thetethering range 504 of the vehicle 100 to initiate the performance ofremote-park assist motive functions by the autonomy unit 138 toautonomously park the vehicle 100 within the parking spot 502. The RePAcontroller 140 of the vehicle 100 in the illustrated example facilitatesprioritization and processing of input requests by determining whetherto process an unlock request based upon a vehicle speed while remotepark-assist is being performed.

The vehicle 100 of the illustrated example is permitted to autonomouslyperform motive functions for remote park-assist when the user 102 iswithin a tethering range 504 of the vehicle 100 and is prohibited fromautonomously performing the motive functions when the user 102 isoutside of the tethering range 504. The RePA controller 140 of theillustrated example determines the distance between the user 102 and theexterior surface of the vehicle 100 based upon signals strengths (e.g.,RSSIs) of low-frequency communication between the key fob 106 of theuser 102 and the communication module 126 of the vehicle 100. Further,BLE communication, Wi-Fi communication, and/or super-high frequencycommunication is utilized to send remote parking signals and/or otherinformation from the mobile device 104 to the RePA controller 140.

In operation, the RePA controller 140 determines whether remotepark-assist is active for the vehicle 100. If the RePA controller 140determines that the remote park-assist is inactive, the RePA controller140 waits to designate a mobile device for initiating remotepark-assist. For example, when the remote park-assist of the vehicle 100is inactive, the RePA controller 140 designates a mobile device uponreceiving, via the communication module 126, an activation request fromthe mobile device. That is, the RePA controller 140 is configured todesignate the mobile device 104 of the user in response to RePAcontroller 140 (i) determining that the remote park-assist is inactiveand (ii) receiving an activation request from the mobile device 104. Insome examples, the mobile device 104 sends the activation request uponthe user opening a remote parking app via the touchscreen 308 of themobile device 104.

In the illustrated example, the autonomy unit 138 of the vehicle 100activates the remote park-assist in response to the RePA controller 140designating the mobile device 104 for the remote park-assist. That is,upon designating the mobile device 104, the RePA controller 140instructs the autonomy unit 138 to activate one or more remotepark-assist features. Further, the RePA controller 140 processes remoteparking signals received by the communication module 126 from the mobiledevice 104 when the mobile device 104 is designated for remotepark-assist of the vehicle 100.

The autonomy unit 138 is configured to perform motive functions forremote park-assist based upon the remote parking signals that are sentfrom the mobile device 104, received by the communication module 126,and processed by the RePA controller 140. That is, the RePA controller140 causes the autonomy unit 138 to perform the remote park-assist uponreceiving the remote parking signals from the mobile device 104 via thecommunication module 126.

In the illustrated example, the autonomy unit 138 performs motivefunctions for remote park-assist based upon the remote parking signalsif the RePA controller 140 (i) identifies a key fob (e.g., the key fob106) that corresponds with the mobile device 104 sending the remoteparking signals and (ii) determines that that key fob is located withinthe tethering range 504 of the vehicle 100. For example, the RePAcontroller 140 determines that the key fob 106 corresponds with themobile device 104 in response to identifying that the distance to and/orlocation of the key fob 106 with respect to the vehicle 100 correspondswith the distance to and/or location of the mobile device 104 withrespect to the vehicle 100. Further, to determine whether the key fob106 is located within the tethering range 504 of the vehicle 100, theRePA controller 140 compares the tethering range 504 to the distancebetween the key fob 106 and the vehicle 100 and/or a relative locationof the key fob 106 with respect to the vehicle 100.

For example, the communication module 126 is configured to determine thedistance between the key fob 106 and the vehicle 100 (with a margin oferror) based upon RSSIs, time-of-flight, and/or angle-of-arrival ofcommunication between the key fob 106 and the communication module 126.In some examples, the communication module 126 also is configured todetermine the distance between the mobile device 104 and the vehicle 100(with a margin of error) based upon RSSIs, time-of-flight, and/orangle-of-arrival of communication between the mobile device 104 and thecommunication module 126. Additionally or alternatively, thecommunication module 126 is configured to utilize triangulation todetermine the location of the mobile device 104 with respect to thevehicle 100 (with a margin of error) based upon RSSIs, time-of-flight,and/or angle-of-arrival of communication between the mobile device 104and the antenna nodes 134. Further, in some examples, the communicationmodule 126 is configured to utilize triangulation to determine thelocation of the key fob 106 with respect to the vehicle 100 (with amargin of error) based upon RSSIs, time-of-flight, and/orangle-of-arrival of communication between the key fob 106 and theantenna nodes 134.

The RePA controller 140 determines that the key fob 106 corresponds withthe mobile device 104 in response to determining that the key fob 106and the mobile device 104 are spaced apart from the vehicle 100 bysimilar distances that are within a threshold margin and/or in responseto determining that the key fob 106 and the mobile device 104 arelocated within a threshold margin of each other. In some examples, ifthe RePA controller 140 is unable to distinguish between two or more keyfobs that are near the mobile device 104 initiating remote park-assist,the RePA controller 140 determines that at least one of those key fobscorresponds with the user 102. Further, in some examples, the RePAcontroller 140 monitors locations of mobile devices including RePAfunctionality and/or key fobs over a period of time to determine thetrajectory of those mobile devices and/or key fobs. In such examples,the RePA controller 140 is configured to identify the key fob 106 thatcorresponds with the mobile device 104 initiating the remote park-assistbased upon the trajectories of the key fob 106 and the mobile device104. Further, in some examples, the RePA controller 140 identifies thekey fob 106 that of the user 102 that corresponds with the mobile device104 based upon direct communication between the mobile device 104 andthe key fob 106.

In the illustrated example, the RePA controller 140 facilitatesprioritization and processing of input requests while remote park-assistis being performed by determining whether to process an unlock requestbased upon a vehicle speed of the vehicle 100. For example, while theautonomy unit 138 is performing remote park-assist, the RePA controller140 is configured to receive an unlock request for unlocking one or moreof the doors 108 (i) from the key fob 106 of the user 102 via thecommunication module 126, (ii) from the key fob 514 and/or the mobiledevice 512 of the user 510 via the communication module 126, (iii)responsive to one of the handle sensors 112 detecting that a user hasengaged and/or otherwise contacted the door handle 110 of thecorresponding one of the doors 108, (iv) from the keypad 114, etc. Inthe illustrated example, the mobile device 512 includes phone-as-a-keyfunctionality.

In some examples, the unlock request is a remote request (e.g., sentfrom the key fob 106, the key fob 514, the mobile device 512). In otherexamples, the unlock request is a local request (e.g., from the keypad114, via one of the handle sensors 112). When the unlock request is aremote request, the RePA controller 140 is configured to determinewhether the mobile device (e.g., the key fob 106, the key fob 514, themobile device 512) that sent the remote request is within the thresholdrange 506 of the vehicle 100. If the mobile device that sent the remoterequest is beyond the threshold range 506, the RePA controller 140prevents unlocking of the doors 108 and the autonomy unit 138 proceedswith performing remote park-assist.

The RePA controller 140 of the illustrated example collects the vehiclespeed from the vehicle speed sensor 124 of the vehicle 100. If the RePAcontroller 140 determines that the vehicle speed is less than or equalto the threshold speed, the RePA controller 140 unlocks and/or primesunlocking for one or more of the doors 108 of the vehicle 100 to enablea user (e.g., the user 102, the user 510) to access the cabin of thevehicle 100. For example, upon the RePA controller 140 determining thatthe vehicle speed is less than or equal to the threshold speed, the RePAcontroller 140 primes the doors 108 for unlocking and the doors 108 aresubsequently unlocked once one of the handle sensors 112 detects that auser has grasped and/or otherwise engaged the door handle 110 of thecorresponding one of the doors 108. Further, in some examples, the RePAcontroller 140 prevents unlocking of the doors 108 while the autonomyunit 138 continues to perform the motive functions for remotepark-assist if the RePA controller 140 determines that the vehicle speedis greater than the threshold speed. In other examples, the RePAcontroller 140 is configured to cause the autonomy unit 138 to stopmovement of the vehicle 100 and performance of remote park-assist upondetermining that the vehicle speed is greater than the threshold speed.In such examples, the RePA controller 140 permits opening of the doors108 once the vehicle 100 has stopped moving.

In some examples, the RePA controller 140 prevents unlocking of thedoors 108 based upon whether a remote unlock signal was sent via apermissible communication protocol. For example, if the remote requestwas sent to the communication module 126 of the vehicle 100 via animpermissible communication protocol (e.g., cellular communication), theRePA controller 140 prevents unlocking of the doors 108 and the autonomyunit 138 proceeds with performing remote park-assist. Further, in someexamples, the RePA controller 140 is configured to process a remote lockrequest and/or a remote emergency request regardless of the speed of thevehicle 100.

FIG. 8 is a flowchart of another example method 800 to manage inputsignals for remote park-assist. The flowchart of FIG. 8 isrepresentative of machine readable instructions that are stored inmemory (such as the memory 210 of FIG. 2) and include one or moreprograms which, when executed by a processor (such as the processor 208of FIG. 2), cause the vehicle 100 to implement the example RePAcontroller 140 of FIGS. 1 and 2. While the example program is describedwith reference to the flowchart illustrated in FIG. 8, many othermethods of implementing the example RePA controller 140 mayalternatively be used. For example, the order of execution of the blocksmay be rearranged, changed, eliminated, and/or combined to perform themethod 800. Further, because the method 800 is disclosed in connectionwith the components of FIGS. 1-4 and 7, some functions of thosecomponents will not be described in detail below.

Initially, at block 802, the RePA controller 140 determines whetherremote park-assist for the vehicle 100 is active. In response to theRePA controller 140 determining that remote park-assist is activated,the method 800 proceeds to block 812. Otherwise, in response to the RePAcontroller 140 determining that remote park-assist is not activated, themethod 800 proceeds to block 804. At block 804, the RePA controller 140determines whether the communication module 126 of the vehicle 100 hasreceived an activation request from a mobile device (e.g., the mobiledevice 104 of the user 102) to activate remote park-assist for thevehicle 100. In response to the RePA controller 140 determining that anactivation request has not been received, the method 800 returns toblock 802. Otherwise, in response to the RePA controller 140 determiningthat an activation request has been received, the method 800 proceeds toblock 806.

At block 806, the RePA controller 140 determines whether there is a keyfob (e.g., the key fob 106 of the user 102) that corresponds with themobile device 104 that sent the activation request for remotepark-assist. For example, the RePA controller 140 determines whether thekey fob 106 corresponds with the mobile device 104 by identifyingwhether the key fob 106 and the mobile device 104 are spaced apart fromthe communication module 126 of the vehicle 100 by similar distancesthat are within a threshold margin and/or by identifying whether the keyfob 106 and the mobile device 104 are located within a threshold marginof each other. In some such examples, the RePA controller 140 determinesthe distance between the key fob 106 and the vehicle 100 based upon asignal strength of communication between the key fob 106 and thecommunication module 126, determines the distance between the mobiledevice 104 and the vehicle 100 based upon a signal strength ofcommunication between the mobile device 104 and the communication module126, and compares the distance of the key fob 106 to the distance of themobile device 104. In response to the RePA controller 140 determiningthat the key fob 106 does not correspond with the mobile device 104, themethod 800 returns to block 802. Otherwise, in response to the RePAcontroller 140 determining that the key fob 106 corresponds with themobile device 104, the method 800 proceeds to block 808.

At block 808, the RePA controller 140 designates the mobile device 104that sent the activation request for initiation of remote park-assistfeatures. At block 810, the RePA controller 140 determines whether thekey fob 106 that corresponds with the mobile device 104 is within thetethering range 504 of the vehicle 100 for initiating remote park-assistfeatures. For example, the RePA controller 140 determines whether thekey fob 106 of the user 102 is within the tethering range 504 based uponsignal strengths of communication between the communication module 126of the vehicle 100 and the key fob 106. In response to the RePAcontroller 140 determining that the user 102 is outside of the tetheringrange 504, the method 800 returns to block 802. Otherwise, in responseto the RePA controller 140 determining that the user 102 is within thetethering range 504, the autonomy unit 138 activates remote park-assistand the method 800 proceeds to block 812 at which the autonomy unit 138performs remote park-assist motive functions initiated via the mobiledevice 104 of the user 102.

At block 814, the RePA controller 140 determines whether the vehicle 100has received an unlock request to unlock one or more of the 108 of thevehicle 100. For example, an unlock request may be received from the keyfob 106 of the user 102, a key fob and/or phone-as-a-key of another user(e.g., the key fob 514 and/or the mobile device 512 of the user 510),the keypad 114, etc. In response to the RePA controller 140 determiningthat an unlock request has not been received, the method 800 returns toblock 802. Otherwise, in response to the RePA controller 140 determiningthat an unlock request has been received, the method 800 proceeds toblock 816.

At block 816, the RePA controller 140 determines whether the receivedunlock request is a remote request. For example, a remote unlock requestincludes an unlock request received by the communication module 126 fromthe key fob 106 of the user 102, a key fob of another user (e.g., thekey fob 514 of the user 510), and/or a phone-as-a-key of another user(e.g., the mobile device 512 of the user 510). An unlock request that isnot a remote request includes a request received from a device on thevehicle 100, such as the handle sensors 112, the keypad 114, theliftgate sensor 118, etc. In response to the RePA controller 140determining that the unlock request is not a remote request, the method800 proceeds to block 822. Otherwise, in response to the RePA controller140 determining that the unlock request is a remote request, the method800 proceeds to block 818.

At block 818, the RePA controller 140 determines whether the remoterequest was sent from a mobile device (e.g., the key fob 106, the mobiledevice 512, the key fob 514) via a permissible communication protocol.For example, an impermissible communication protocol includes a cellularcommunication protocol, and permissible communication protocols includea Bluetooth low-energy protocol, a Wi-Fi communication protocol, andsuper-high frequency communication. In response to the RePA controller140 determining that the remote request was not sent via a permissiblecommunication protocol, the method 800 returns to block 802. Otherwise,in response to the RePA controller 140 determining that the remoterequest was sent via a permissible communication protocol, the method800 proceeds to block 820.

At block 820, the RePA controller 140 determines whether the mobiledevice (e.g., the key fob 106, the mobile device 512, the key fob 514)that sent the remote unlock request is within the threshold range 506 ofthe vehicle 100. For example, the RePA controller 140 determines whetherthe mobile device is within the threshold range 506 based upon signalstrengths of communication between the mobile device and thecommunication module 126 of the vehicle 100. In response to the RePAcontroller 140 determining that the mobile device is beyond thethreshold range 506, the method 800 returns to block 802. Otherwise, inresponse to the RePA controller 140 determining that the mobile deviceis within the threshold range 506, the method 800 proceeds to block 822.

At block 822, the RePA controller 140 determines whether the currentvehicle speed of the vehicle 100 is greater than a threshold speed. Forexample, the RePA controller 140 determines the vehicle speed via thevehicle speed sensor 124 while the autonomy unit 138 is performingmotive functions for remote park-assist. In response to the RePAcontroller 140 determining that the vehicle speed is less than or equalto the threshold speed, the method 800 proceeds to block 824 at whichthe RePA controller 140 unlocks and/or primes for unlocking of one ormore of the doors 108 of the vehicle 100. Otherwise, in response to theRePA controller 140 determining that the vehicle speed is greater thanthe threshold speed, the method 800 proceeds to block 826 at which theRePA controller 140 prevents unlocking of the doors 108 while theautonomy unit 138 continues to perform the motive functions for remotepark-assist. Additionally or alternatively, the RePA controller 140, atblock 828, causes the autonomy unit 138 to stop movement of the vehicle100 and performance of remote park-assist. For example, the RePAcontroller 140 facilitates opening of the doors 108 once movement of thevehicle 100 is stopped.

FIG. 9 depicts another example system for managing input signals forremote park-assist of the vehicle 100. In the illustrated example, theuser 102 utilizes the mobile device 104 when the user 102 is within thetethering range 504 of the vehicle 100 to initiate the performance ofremote-park assist motive functions by the autonomy unit 138 toautonomously park the vehicle 100 within the parking spot 502. The RePAcontroller 140 of the vehicle 100 of the illustrated example facilitateprioritization of input requests by determining whether to process aremote unlock request based upon a number of key fobs that areidentified as being within the tethering range 504 of the vehicle 100while remote park-assist is being performed.

The vehicle 100 of the illustrated example is permitted to autonomouslyperform motive functions for remote park-assist when the user 102 iswithin a tethering range 504 of the vehicle 100 and is prohibited fromautonomously performing the motive functions when the user 102 isoutside of the tethering range 504. The RePA controller 140 of theillustrated example determines the distance between the user 102 and theexterior surface of the vehicle 100 based upon signals strengths (e.g.,RSSIs) of low-frequency communication between the key fob 106 of theuser 102 and the communication module 126 of the vehicle 100. Further,BLE communication, Wi-Fi communication, and/or super-high frequencycommunication is utilized to send remote parking signals and/or otherinformation from the mobile device 104 to the RePA controller 140.

In operation, the RePA controller 140 determines whether remotepark-assist is active for the vehicle 100. If the RePA controller 140determines that the remote park-assist is inactive, the RePA controller140 waits to designate a mobile device for initiating remotepark-assist. For example, when the remote park-assist of the vehicle 100is inactive, the RePA controller 140 designates a mobile device uponreceiving, via the communication module 126, an activation request fromthe mobile device. That is, the RePA controller 140 is configured todesignate the mobile device 104 of the user in response to RePAcontroller 140 (i) determining that the remote park-assist is inactiveand (ii) receiving an activation request from the mobile device 104. Insome examples, the mobile device 104 sends the activation request uponthe user opening a remote parking app via the touchscreen 308 of themobile device 104.

In the illustrated example, the autonomy unit 138 of the vehicle 100activates the remote park-assist in response to the RePA controller 140designating the mobile device 104 for the remote park-assist. That is,upon designating the mobile device 104, the RePA controller 140instructs the autonomy unit 138 to activate one or more remotepark-assist features. Further, the RePA controller 140 processes remoteparking signals received by the communication module 126 from the mobiledevice 104 when the mobile device 104 is designated for remotepark-assist of the vehicle 100.

The autonomy unit 138 is configured to perform motive functions forremote park-assist based upon the remote parking signals that are sentfrom the mobile device 104, received by the communication module 126,and processed by the RePA controller 140. That is, the RePA controller140 causes the autonomy unit 138 to perform the remote park-assist uponreceiving the remote parking signals from the mobile device 104 via thecommunication module 126.

In the illustrated example, the autonomy unit 138 performs motivefunctions for remote park-assist based upon the remote parking signalsif the RePA controller 140 (i) identifies a key fob (e.g., the key fob106) that corresponds with the mobile device 104 sending the remoteparking signals and (ii) determines that that key fob is located withinthe tethering range 504 of the vehicle 100. For example, the RePAcontroller 140 determines that the key fob 106 corresponds with themobile device 104 in response to identifying that the distance to and/orlocation of the key fob 106 with respect to the vehicle 100 correspondswith the distance to and/or location of the mobile device 104 withrespect to the vehicle 100. Further, to determine whether the key fob106 is located within the tethering range 504 of the vehicle 100, theRePA controller 140 compares the tethering range 504 to the distancebetween the key fob 106 and the vehicle 100 and/or a relative locationof the key fob 106 with respect to the vehicle 100.

For example, the communication module 126 is configured to determine thedistance between the key fob 106 and the vehicle 100 (with a margin oferror) based upon RSSIs, time-of-flight, and/or angle-of-arrival ofcommunication between the key fob 106 and the communication module 126.In some examples, the communication module 126 also is configured todetermine the distance between the mobile device 104 and the vehicle 100(with a margin of error) based upon RSSIs, time-of-flight, and/orangle-of-arrival of communication between the mobile device 104 and thecommunication module 126. Additionally or alternatively, thecommunication module 126 is configured to utilize triangulation todetermine the location of the mobile device 104 with respect to thevehicle 100 (with a margin of error) based upon RSSIs, time-of-flight,and/or angle-of-arrival of communication between the mobile device 104and the antenna nodes 134. Further, in some examples, the communicationmodule 126 is configured to utilize triangulation to determine thelocation of the key fob 106 with respect to the vehicle 100 (with amargin of error) based upon RSSIs, time-of-flight, and/orangle-of-arrival of communication between the key fob 106 and theantenna nodes 134.

The RePA controller 140 determines that the key fob 106 corresponds withthe mobile device 104 in response to determining that the key fob 106and the mobile device 104 are spaced apart from the vehicle 100 bysimilar distances that are within a threshold margin and/or in responseto determining that the key fob 106 and the mobile device 104 arelocated within a threshold margin of each other. In some examples, ifthe RePA controller 140 is unable to distinguish between two or more keyfobs that are near the mobile device 104 initiating remote park-assist,the RePA controller 140 determines that at least one of those key fobscorresponds with the user 102. Further, in some examples, the RePAcontroller 140 monitors locations of mobile devices including RePAfunctionality and/or key fobs over a period of time to determine thetrajectory of those mobile devices and/or key fobs. In such examples,the RePA controller 140 is configured to identify the key fob 106 thatcorresponds with the mobile device 104 initiating the remote park-assistbased upon the trajectories of the key fob 106 and the mobile device104. Further, in some examples, the RePA controller 140 identifies thekey fob 106 that of the user 102 that corresponds with the mobile device104 based upon direct communication between the mobile device 104 andthe key fob 106.

In the illustrated example, the RePA controller 140 facilitatesprioritization and processing of input requests while remote park-assistis being performed by determining whether to process a remote unlockrequest based upon a number of key fobs that are identified as beingwithin the tethering range 504 of the vehicle 100. For example, whilethe autonomy unit 138 is performing remote park-assist, the RePAcontroller 140 is configured to receive, via the communication module126, an unlock request for unlocking one or more of the doors 108 (i)from the key fob 106 of the user 102, (ii) from the key fob 514 of theuser 510, (iii) from a key fob of another user associated with thevehicle 100.

If the RePA controller 140 identifies that the key fob which sent theunlock request is located beyond the tethering range 504, the RePAcontroller 140 determines that the unlock request was not sent from thekey fob 106 of the user 102 initiating remote park-assist via the mobiledevice 104. That is, the RePA controller 140 determines that the unlockrequest was sent from another key fob other than the key fob 104. Insuch instances, it is assumed that another user (e.g., the user 510)intentionally sent the unlock request to unlock one or more of the doors108 while the user 102 is initiating remote park-assist via the mobiledevice 104. In turn, the RePA controller 140 causes the autonomy unit138 to stop movement of the vehicle 100 and performance of remotepark-assist if the key fob that sent the unlock request is within thethreshold range 506 of the vehicle 100. Further, the RePA controller 140is configured to permit opening of the doors 108 once the vehicle 100has stopped moving. In some examples, once the vehicle 100 isstationary, the RePA controller 140 unlocks and/or primes unlocking forone or more of the doors 108 of the vehicle 100 to enable a user (e.g.,the user 102, the user 510) to access the cabin of the vehicle 100. Forexample, the RePA controller 140 primes the doors 108 for unlocking suchthat the RePA controller 140 unlocks one or more of the doors 108 inresponse to (i) one of the handle sensors 112 detecting that the doorhandle 110 of one of the doors 108 has been engaged by a user and (ii)the RePA controller 140 detecting that a key fob and/or phone-as-a-keyis near the corresponding one of the doors 108.

Otherwise, upon receiving an unlock request from a key fob within thetethering range 504, the RePA controller 140 identifies the number ofkey fob(s) within the tethering range 504. For example, the RePAcontroller 140 identifies the number of key fob(s) near the vehicle 100based upon the communication signals (e.g., beacons, pings, inputsignals, etc.) that are received by the communication module 126 of thevehicle 100. That is, the RePA controller 140 identifies the number ofkey fob(s) near the vehicle 100 by identifying the number of key fob(s)in communication with the communication module 126 of the vehicle 100.Further, the RePA controller 140 identifies the number of key fob(s)that within the tethering range 504 by identifying which of those keyfob(s) in communication with the communication module 126 are within thetethering range 504 of the vehicle 100. The RePA controller 140 isconfigured to determined which of those key fob(s) are within thetethering range 504 based upon signals strengths of the communicationsignals between the key fob(s) and the communication module 126.

In response to the RePA controller 140 determining that the number ofkey fob(s) within the tethering range 504 is one, the RePA controller140 prevents the doors 108 from unlocking and the autonomy unit 138continues to perform the motive functions for remote park-assist. Thatis, the RePA controller 140 does not process the unlock request if thenumber of key fob(s) within the tethering range 504 is one. For example,if the number of key fob(s) within the tethering range 504 is one, theRePA controller 140 determines that the unlock request was sent from thekey fob 106 of the user 102 that is initiating performance of the remotepark-assist via the mobile device 104. In such instances, it is assumedthat the user 102 did not intend to send an unlock request via the keyfob 106 while initiating the remote park-assist via the mobile device104. In turn, the RePA controller 140 ignores the unlock request sentfrom the key fob 106 to facilitate prioritization of input requestswhile remote park-assist is being performed.

In response to the RePA controller 140 determining that the number ofkey fob(s) within the tethering range 504 is two or more, the RePAcontroller 140 attempts to determine whether the unlock request was sentfrom the key fob 106 of the user 102 that corresponds with the mobiledevice 104 initiating the remote park-assist. To determine whether theunlock request was sent from the key fob 106 of the user 102, the RePAcontroller 140 compares the relative distance(s) and/or location(s) ofeach of the key fob(s) with respect to the vehicle 100 within thetethering range 504 to the distance between the mobile device 104 andthe vehicle 100 and/or a location of the mobile device 104 relative tothe vehicle 100.

If the RePA controller 140 identifies that the key fob which sent theunlock request (i) is spaced apart from the vehicle 100 by a differentdistance than the mobile device 104 and/or (ii) is at a differentlocation than the mobile device initiating remote park-assist, the RePAcontroller 140 determines that the unlock request was not sent from thekey fob 106 of the user 102 initiating remote park-assist via the mobiledevice 104. That is, the RePA controller 140 determines that the unlockrequest was sent from another key fob (e.g., the key fob 514). In suchinstances, it is assumed that another user (e.g., the user 510)intentionally sent the unlock request to unlock one or more of the doors108 while the user 102 is initiating remote park-assist via the mobiledevice 104. In turn, the RePA controller 140 causes the autonomy unit138 to stop movement of the vehicle 100 and performance of remotepark-assist. Further, the RePA controller 140 is configured to permitopening of the doors 108 once the vehicle 100 has stopped moving. Insome examples, once the vehicle 100 is stationary, the RePA controller140 unlocks and/or primes unlocking for one or more of the doors 108 ofthe vehicle 100 to enable a user (e.g., the user 102, the user 510) toaccess the cabin of the vehicle 100. For example, the RePA controller140 primes the doors 108 for unlocking such that the RePA controller 140unlocks one or more of the doors 108 in response to (i) one of thehandle sensors 112 detecting that the door handle 110 of one of thedoors 108 has been engaged by a user and (ii) the RePA controller 140detecting that a key fob and/or phone-as-a-key is near the correspondingone of the doors 108.

If the RePA controller 140 identifies that the key fob which sent theunlock request is the only one of the key fob(s) that is (i) locatedwithin a threshold distance of the mobile device 104 initiating remotepark-assist and/or (ii) spaced apart from the vehicle 100 by the same orsimilar distances within a threshold margin of the mobile device 104initiating remote park-assist, the RePA controller 140 determines thatthe unlock request was sent from the key fob 106 of the user 102initiating remote park-assist via the mobile device 104. In response todetermining that the unlock request was sent from the key fob 106 of theuser 102, the RePA controller 140 prevents the doors 108 from unlockingand the autonomy unit 138 continues to perform the motive functions forremote park-assist. That is, it is assumed that the user 102 did notintend to send an unlock request via the key fob 106 while initiatingthe remote park-assist via the mobile device 104. In such instances, theRePA controller 140 does not process the unlock request sent from thekey fob 106 to further facilitate prioritization of input requests whileremote park-assist is being performed.

Further, in some examples, the RePA controller 140 potentially may beunable to determine whether the key fob which sent the unlock requestcorresponds with the mobile device 104 initiating remote park-assist.For example, the RePA controller 140 is unable to determine whether thekey fob sending the unlock request corresponds with the mobile device104 initiating remote park-assist if the RePA controller 140 identifiesthat the key fob which sent the unlock signal, other key fob(s) whichdid not send the unlock signal, and the mobile device 104 initiatingremote park-assist are located within a threshold distance each otherand/or are spaced apart from the vehicle 100 by similar distances withina threshold margin.

In some examples, when the RePA controller 140 is unable to determinewhether the key fob that sent the unlock request is the key fob 106 ofthe user 102 initiating remote park-assist via the mobile device 104,the RePA controller 140 causes the autonomy unit 138 to stop movement ofthe vehicle 100 and performance of remote park-assist. That is, it isassumed that the unlock request was sent unintentionally while themobile device 104 is initiating the remote park-assist. Further, theRePA controller 140 is configured to permit opening of the doors 108once the vehicle 100 has stopped moving. In some examples, once thevehicle 100 is stationary, the RePA controller 140 unlocks and/or primesunlocking for one or more of the doors 108 of the vehicle 100 to enablea user (e.g., the user 102, the user 510) to access the cabin of thevehicle 100.

In other examples, when the RePA controller 140 is unable to determinewhether the key fob that sent the unlock request is the key fob 106 ofthe user 102 initiating remote park-assist via the mobile device 104,the RePA controller 140 prevents the doors 108 from unlocking and theautonomy unit 138 continues to perform the motive functions for remotepark-assist. That is, it is assumed that the unlock request was sentunintentionally while the mobile device 104 is initiating the remotepark-assist. In such instances, the RePA controller 140 does not processthe unlock request sent from the key fob 106 to further facilitateprioritization of input requests while remote park-assist is beingperformed.

FIG. 10 is a flowchart of another example method 1000 to manage inputsignals for remote park-assist. The flowchart of FIG. 10 isrepresentative of machine readable instructions that are stored inmemory (such as the memory 210 of FIG. 2) and include one or moreprograms which, when executed by a processor (such as the processor 208of FIG. 2), cause the vehicle 100 to implement the example RePAcontroller 140 of FIGS. 1 and 2. While the example program is describedwith reference to the flowchart illustrated in FIG. 10, many othermethods of implementing the example RePA controller 140 mayalternatively be used. For example, the order of execution of the blocksmay be rearranged, changed, eliminated, and/or combined to perform themethod 1000. Further, because the method 1000 is disclosed in connectionwith the components of FIGS. 1-4 and 9, some functions of thosecomponents will not be described in detail below.

Initially, at block 1002, the RePA controller 140 determines whetherremote park-assist for the vehicle 100 is active. In response to theRePA controller 140 determining that remote park-assist is activated,the method 1000 proceeds to block 1012. Otherwise, in response to theRePA controller 140 determining that remote park-assist is notactivated, the method 1000 proceeds to block 1004. At block 1004, theRePA controller 140 determines whether the communication module 126 ofthe vehicle 100 has received an activation request from a mobile device(e.g., the mobile device 104 of the user 102) to activate remotepark-assist for the vehicle 100. In response to the RePA controller 140determining that an activation request has not been received, the method1000 returns to block 1002. Otherwise, in response to the RePAcontroller 140 determining that an activation request has been received,the method 1000 proceeds to block 1006.

At block 1006, the RePA controller 140 determines whether there is a keyfob (e.g., the key fob 106 of the user 102) that corresponds with themobile device 104 that sent the activation request for remotepark-assist. For example, the RePA controller 140 determines whether thekey fob 106 corresponds with the mobile device 104 by identifyingwhether the key fob 106 and the mobile device 104 are located within athreshold distance each other and/or are spaced apart from thecommunication module 126 of the vehicle 100 by similar distances withina threshold margin. In some such examples, the RePA controller 140determines the distance and/or relative location between the key fob 106and the vehicle 100 based upon a signal strength of communicationbetween the key fob 106 and the antenna nodes 134, determines thedistance and/or relative location between the mobile device 104 and thevehicle 100 based upon a signal strength of communication between themobile device 104 and the antenna nodes 134, and compares the distanceand/or location of the key fob 106 to the distance and/or location ofthe mobile device 104. In response to the RePA controller 140determining that the key fob 106 does not correspond with the mobiledevice 104, the method 1000 returns to block 1002. Otherwise, inresponse to the RePA controller 140 determining that the key fob 106corresponds with the mobile device 104, the method 1000 proceeds toblock 1008.

At block 1008, the RePA controller 140 designates the mobile device 104that sent the activation request for initiation of remote park-assistfeatures. At block 1010, the RePA controller 140 determines whether thekey fob 106 that corresponds with the mobile device 104 is within thetethering range 504 of the vehicle 100 for initiating remote park-assistfeatures. For example, the RePA controller 140 determines whether thekey fob 106 of the user 102 is within the tethering range 504 based uponsignal strengths of communication between the communication module 126of the vehicle 100 and the key fob 106. In response to the RePAcontroller 140 determining that the user 102 is outside of the tetheringrange 504, the method 1000 returns to block 1002. Otherwise, in responseto the RePA controller 140 determining that the user 102 is within thetethering range 504, the autonomy unit 138 activates remote park-assistand the method 1000 proceeds to block 1012 at which the autonomy unit138 performs remote park-assist motive functions initiated via themobile device 104 of the user 102.

At block 1014, the RePA controller 140 determines a number of key fob(s)that are within the tethering range 504 of the vehicle 100. For example,the RePA controller 140 identifies the number of key fob(s) within thetethering range 504 based upon communication signals received by thecommunication module 126 of the vehicle 100 (from the key fob(s)). Atblock 1016, the RePA controller 140 determines whether the communicationmodule 126 has received a door unlock request from one of the keyfob(s). In response to the RePA controller 140 determining that anunlock request has not been received from one of the key fob(s), themethod 1000 returns to block 1002. Otherwise, in response to the RePAcontroller 140 determining that an unlock request has been received fromone of the key fob(s), the method 1000 proceeds to block 1018.

At block 1018, the RePA controller 140 determines whether the number ofkey fob(s) within the tethering range 504 is one. In response to theRePA controller 140 determining that the number of key fob(s) within thetethering range 504 is one, the method 1000 proceeds to block 1020 atwhich the RePA controller 140 prevents unlocking of the doors 108 whilethe autonomy unit 138 continues to perform the motive functions forremote park-assist. Otherwise, in response to the RePA controller 140determining that the number of key fob(s) within the tethering range 504is not one, the method 1000 proceeds to block 1022.

At block 1022, the RePA controller 140 determines whether the unlockrequest was sent from the key fob 106 that corresponds with the mobiledevice 104 initiating the remote park-assist. For example, the RePAcontroller 140 determines whether a key fob sending an unlock requestcorresponds with the mobile device 104 by identifying that (i) the keyfob sending the unlock request and the mobile device 104 are locatedwithin a threshold distance of each other and/or are spaced apart fromthe communication module 126 of the vehicle 100 by similar distancesthat are within a threshold margin and (ii) other key fob(s) within thetethering zone are at different locations and/or are spaced apart fromthe communication module 126 by different distance(s). In response tothe RePA controller 140 determining that the key fob sending the unlockrequest was corresponds with the mobile device 104, the method 1000proceeds to block 1024 at which the RePA controller 140 preventsunlocking of the doors 108 while the autonomy unit 138 continues toperform the motive functions for remote park-assist. Otherwise, inresponse to the RePA controller 140 not determining that the key fobsending the unlock request was corresponds with the mobile device 104(e.g., the RePA controller 140 determined that the unlock request wassent from another key fob, the RePA controller 140 was unable toidentify the key fob sending the unlock request), the method 1000proceeds to block 1026.

At block 1026, the RePA controller 140 determines whether the unlockrequest sent from one of the key fob(s) is within the threshold range506. For example, the RePA controller 140 determines whether the key fobsending the unlock request is within the threshold range 506 based uponsignal strengths of communication between that key fob and thecommunication module 126 of the vehicle 100. In response to the RePAcontroller 140 determining that the key fob sending the unlock requestis beyond the threshold range 506, the method 1000 returns to block1002. Otherwise, in response to the RePA controller 140 determining thatthe mobile device is within the threshold range 506, the method 1000proceeds to block 1028 at which the RePA controller 140 causes theautonomy unit 138 to stop movement of the vehicle 100 and facilitatesopening of the doors 108 once movement of the vehicle 100 is stopped(e.g., by unlocking the doors 108, by priming the doors 108 forunlocking).

An example disclosed vehicle includes an autonomy unit for remoteparking, a communication module, a sensor, and a controller. Thecontroller is to designate a phone-as-a-key (PaaK) responsive todetermining the remote parking is inactive and receiving an activationrequest from the PaaK. When the PaaK is designated, the controller alsois to process remote parking signals of the PaaK, stop the remoteparking when the sensor detects engagement of a door handle, and preventprocessing of other nonemergency requests.

In some examples, the communication module is configured to communicatewith the PaaK via at least one of a Bluetooth low-energy protocol, aWi-Fi protocol, cellular communication, and super-high frequencycommunication. In some examples, the sensor is a door handle sensor.

In some examples, the autonomy unit activates the remote parking inresponse to the controller designating the PaaK for the remote parking.In some examples, the autonomy unit performs the remote parking basedupon the remote parking signals received by the communication modulefrom the PaaK.

In some examples, the autonomy unit is configured to stop vehicle motivefunctions of the remote parking upon receipt of an emergency signal foran emergency event. In some such examples, the communication module isconfigured to receive the emergency signal from PaaKs and key fobs. Insome such examples, the emergency signal includes a panic request signalreceived by the communication module. In some such examples, theemergency signal includes a plurality of requests received by thecommunication module within a predefined time period. In some suchexamples, the emergency event includes an obstacle being positionedalong a vehicle path of the vehicle motive functions.

In some examples, the controller is configured to receive thenonemergency requests from one or more PaaKs, one or more key fobs, avehicle keypad, a liftgate sensor, and a cellular network. In someexamples, the nonemergency requests include a second activation requestfrom a second PaaK. In some such examples, the controller sends, via thecommunication module, an alert to the second PaaK indicating that thePaaK is currently designated for the remote parking. In some suchexamples, upon receiving the second activation request from the secondPaaK, the controller sends, via the communication module, a request tothe PaaK for permission to change designation for the remote parking tothe second PaaK. In some examples, the nonemergency requests includepassive-entry passive-start signals and remote keyless entry signals. Insome examples, the nonemergency requests include a remote door unlockrequest.

In some examples, when the remote parking is stopped, the controller isconfigured to unlock a door in response to the sensor detectingengagement with the door handle.

An example disclosed method includes designating, via processor, aphone-as-a-key (PaaK) for remote parking responsive to determining theremote parking is inactive and receiving, via a communication module, anactivation request from the PaaK. The example disclosed method alsoincludes processing, via an autonomy unit, remote parking signals of thePaaK and preventing processing of other nonemergency requests during theremote parking. The example disclosed method also includes stopping, viathe autonomy unit, the remote parking upon a sensor detecting engagementof a door handle.

Some examples further include stopping vehicle motive functions of theremote parking upon receipt of an emergency signal for an emergencyevent. Some such examples further include, upon stopping the vehiclemotive functions, unlocking a door in response to the sensor detectingengagement with the door handle.

In this application, the use of the disjunctive is intended to includethe conjunctive. The use of definite or indefinite articles is notintended to indicate cardinality. In particular, a reference to “the”object or “a” and “an” object is intended to denote also one of apossible plurality of such objects. Further, the conjunction “or” may beused to convey features that are simultaneously present instead ofmutually exclusive alternatives. In other words, the conjunction “or”should be understood to include “and/or”. The terms “includes,”“including,” and “include” are inclusive and have the same scope as“comprises,” “comprising,” and “comprise” respectively. Additionally, asused herein, the terms “module,” “unit,” and “node” refer to hardwarewith circuitry to provide communication, control and/or monitoringcapabilities, often in conjunction with sensors. A “module,” a “unit,”and a “node” may also include firmware that executes on the circuitry.

The above-described embodiments, and particularly any “preferred”embodiments, are possible examples of implementations and merely setforth for a clear understanding of the principles of the invention. Manyvariations and modifications may be made to the above-describedembodiment(s) without substantially departing from the spirit andprinciples of the techniques described herein. All modifications areintended to be included herein within the scope of this disclosure andprotected by the following claims.

What is claimed is: 1-20. (canceled)
 21. A vehicle comprising: anautonomy unit for remote parking; a communication module; a sensor; anda controller to: designate a first mobile device responsive to:determining the remote parking is inactive; and receiving a firstactivation request from the first mobile device; receiving a secondactivation request from a second mobile device; and denying the secondactivation request; and when the first mobile device is designated:process remote parking signals of the first mobile device; and preventprocessing of other nonemergency requests.
 22. The vehicle of claim 21,wherein the controller is configured to send, via the communicationmodule, an alert to the second mobile device indicating that the firstmobile device is currently designated.
 23. The vehicle of claim 22,wherein the controller is configured to send, via the communicationmodule, an alert to the second mobile device indicating a duration oftime during which the first mobile device will remain designated. 24.The vehicle of claim 21, wherein the controller is configured to send,via the communication module, a request to the first mobile device forpermission to change designation to the second mobile device.
 25. Thevehicle of claim 21, wherein the communication module is configured tocommunicate with the first mobile device or the second mobile device viaa Bluetooth low-energy protocol, a Wi-Fi protocol, cellularcommunication, Ultra-Wide Band communication, and/or super-highfrequency communication.
 26. The vehicle of claim 21, wherein theautonomy unit activates the remote parking in response to the controllerdesignating the first mobile device for the remote parking.
 27. Thevehicle of claim 21, wherein the autonomy unit performs the remoteparking based upon the remote parking signals received by thecommunication module from the first mobile device.
 28. The vehicle ofclaim 21, wherein the autonomy unit is configured to stop vehicle motivefunctions of the remote parking upon receipt of an emergency signal foran emergency event.
 29. The vehicle of claim 28, wherein the emergencysignal for the emergency event is received from the first mobile deviceor the second mobile device.
 30. The vehicle of claim 28, wherein thecommunication module is configured to receive the emergency signal fromphones-as-keys and key fobs.
 31. The vehicle of claim 28, wherein theemergency signal includes a panic request signal received by thecommunication module.
 32. The vehicle of claim 28, wherein the emergencysignal includes a plurality of requests received by the communicationmodule within a predefined time period.
 33. The vehicle of claim 28,wherein the emergency event includes an obstacle being positioned alonga vehicle path of the vehicle motive functions.
 34. The vehicle of claim21, wherein the controller is configured to receive the nonemergencyrequests from one or more phones-as-keys, one or more key fobs, avehicle keypad, a liftgate sensor, and a cellular network.
 35. Thevehicle of claim 21, wherein the controller is configured to prioritizecompeting activation requests from competing mobile devices.
 36. Thevehicle of claim 21, wherein the nonemergency requests includepassive-entry passive-start signals and remote keyless entry signals.37. The vehicle of claim 21, wherein the nonemergency requests include aremote door unlock request.
 38. The vehicle of claim 21, wherein, whenthe remote parking is stopped, the controller is configured to unlock adoor in response to the sensor detecting engagement with the doorhandle.
 39. A method comprising: designating, via processor, a firstmobile device for remote parking responsive to: determining the remoteparking is inactive; and receiving, via a communication module, anactivation request from the first mobile device; receiving a secondactivation request from a second mobile device; and denying the secondactivation request; processing, via an autonomy unit, remote parkingsignals of the first mobile device; and preventing processing of othernonemergency requests during the remote parking.
 40. The method of claim39, prioritizing competing activation requests from competing mobiledevices.